Automation systems for controlling a technical process or a technical installation usually comprise a control device (PLC), which are integrated in a complex comprising a multiplicity of intelligent electrical devices. Intelligent electronic devices are microprocessor-based devices such as protective and control devices, motor protection devices, intelligent switches and voltage regulators, frequency converters, pressure and temperature measurement transducers, flowmeters and servo drives.
The article “FDI Device Integration—Best of Both Worlds”, atp edition June 2010, pages 16 to 19, discloses the practice of integrating field devices with the FDI concept (Field Device Integration IEC—62769) into an automation installation. The basis for this concept is the provision of information for configuring field devices in a device-specific FDI package. This FDI package comprises a firmly prescribed quantity of information that consists of device definition, business logic, user interface description and user interface plugins. The device definition comprises management information and the device model. The business logic describes the communication logic for the device and is used for ensuring consistency for the device model. The user interface description describes the presentation of the device parameters and device functions. The user interface plugins are programmed components of interface portions for presenting the device parameters and functions.
When field devices are configured by means of EDD (Electronic Device Description) technology IEC 61804, a device manufacturer provides an EDD that contains information about the communication with the device, the business logic and the user interfaces, that is to say what input masks should be presented to a user. By way of example, the business logic includes when what parameters can be written.
FDI technology uses these mechanisms of the EDD and provides the concept of the FDI package, in which, besides an EDD, other information such as a user handbook can be included, but also what are known as UIPs (User Interface Plugins), which provide further user interfaces in other technologies, such as .NET Assemblies, which, in contrast to EDD-based user interfaces, consist of programmed code compiled to form a component.
FDI packages are typically produced by device manufacturers and used by system manufacturers in order to integrate and configure the devices of the device manufacturers in their system.
The EDD may define not only a single user element with various parameters, graphs and other elements but also new windows and dialogs. In this case, a host has certain degrees of freedom and, by way of example, can present a plurality of menus defined in the EDD in different windows simultaneously, or else user interfaces of different device instances.
Known EDD host systems either restrict the number of windows or open any number of windows for the different devices. The user then loses sight of the association between the windows and the devices.
Furthermore, the EDD specification allows an input context to be defined that contains changes to a device configuration that the user has already made on the interface but has not yet written to the device or the offline configuration. In this case, it is possible, according to the specification, for different windows and dialogs to work on different input contexts for the same device. This concept makes it even more difficult for a user to associate the windows not just with the device but also with a particular input context.
According to the prior art, EDD host systems display the windows described in the EDD as windows of the application, so that the user can compare a plurality of window contents with one another. However, the windows are quite difficult to associate with a particular device instance and even more difficult to associate with a particular input context of this device instance. When a user wishes to apply or reject an input context, it is therefore difficult to identify which windows are affected thereby.
In such a programming tool, information relating to the devices is visualized and functions such as parameterization operations are performed. To this end, the user first needs to select a device from a multiplicity of devices.
In known programming tools, one and the same device is furthermore disadvantageously presented in different ways. For example, a different device object and symbol is displayed in the tree structure than in the list presentation of the devices. The device functionality also differs on the basis of the form of presentation. The presentation is nonuniform and therefore difficult for the user to learn. The different presentations also differ in terms of device functionality that the user can perform. Hence, the user cannot perform the same design functions in the list presentation as if he were to take the device object in the tree. The user thus has to know in which presentation he can find and perform which device functions.
The user has the option of bringing already open windows or presentations to the foreground. For this, there are various options that are all based on a preview. This preview is either always visible and shows all currently open windows or else the user moves the mouse over an application and is then provided with a display of a preview of the open windows of this application.
The preview of the open windows is not directly related to the program functions that have been used to open the individual windows. There is therefore no possibility of association of the operator control element that has been used to open this window. Hence, the user cannot explicitly identify how he can open a similar window or with what functionality an open window is associated.
DE 102 45 890 B4 discloses a screen element, HMI device, automation system and computer program product for visualization and project planning for singly and repeatedly used user texts and the points of use that are assigned in a data processing system. The disclosure reveals that the devices are provided for selection in a hierarchic tree structure, with each branch that ramifies further having an associated user text and each branch that does not ramify further having an associated combination of a user text and a point of use. Details for a device are stored in nested menu levels. This turns operator control and particularly searching for details for a device into a time consuming process.